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1  INTRODUCTION 


The  purpose  of  this  contract  is  to  develop  software  to  predict  the  effects  of 
weather  and  other  environmental  factors  on  the  performance  of  electro-optical  (EO) 
(infrared,  visible,  and  laser)  weapons  systems.  These  Weather  Impact  Decision  Aids 
(WIDAs)  will  be  used  to  support  the  mission  planning  and  mission  execution  process. 
The  WIDA  program  is  broken  down  into  two  software  development  programs.  The 
Weather  Automated  Mission  Planning  Software  (WAMPS)  will  be  a  demonstratable 
system  showing  how  weather  decision  aids  can  benefit  the  mission  planning  process.  The 
Target  Acquisition  Weather  Software  (TAWS)  will  be  fielded  to  replace  the  aging  DOS- 
based  Electro-Optical  Tactical  Decision  Aid  (EOTDA)  software.  TAWS  takes  advantage 
of  the  latest  hardware  and  software  technology  improvements,  and  will  integrate 
advances  in  environmental  effects  modeling.  Additionally,  TAWS  will  leverage 
developments  already  underway  at  the  Air  Force  Research  Laboratory  (AFRL)  in  its 
Infrared  Target  Scene  Simulation  (IRTSS)  and  Night  Vision  Goggles  Operations  Weather' 
Software  (NOWS)  programs.  Together,  these  programs  will  significantly  enhance 
support  to  the  warfighter.  In  the  modem  era  when  hundreds  to  thousands  of  sorties  may 
be  flown  over  a  very  short  period  of  time  using  precision  guided  munitions,  automation 
and  the  inclusion  of  mission-limiting  weather  effects  is  essential. 


1.1  OBJECTIVES 

The  WIDA  work  is  divided  into  three  task  areas  and  is  being  conducted  over  an 
approximately  four-year  period.  The  WIDA  project  schedule  is  shown  in  Figure  1.  A 
brief  description  of  the  task  areas  is  provided  below. 

1.1.1  Task  1:  Weather  Automated  Mission  Planning  Software  (WAMPS) 

A  demonstratable  Weather  Automated  Mission  Planning  Software  (WAMPS) 
system  will  be  incrementally  developed.  WAMPS  will  be  capable  of  showing  how 
weather  decision  aids  can  support  and  improve  the  mission  planning  process.  WAMPS 
will  demonstrate  how  WIDAs  can  be  used  as  force  multipliers  in  automated  mission 
planning  systems  by  facilitating  the  effective  use  of  EO  weapon  systems  against  enemy 
targets.  The  WAMPS  demonstration  product  will  be  developed  in  four  stages.  Focal 
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points  will  be  overall  system  look  and  feel,  integration  of  key  databases,  execution  of 
WIDA  models,  and  demonstration  of  value  added. 


Figure  1.  WIDA  Project  Schedule. 


1.1.2  Task  2:  Target  Acquisition  Weather  Software  (TAWS) 

Target  Acquisition  Weather  Software  (TAWS)  is  being  developed  to  replace  the 
EO  Tactical  Decision  Aid  (EOTDA),  integrating  recent  modeling  and  hardware/software 
technology  improvements.  TAWS  will  incorporate  a  modular  system  design,  a  Graphical 
User  Interface  (GUI)  that  maximizes  usability,  enhanced  output  products  that  can  be 
tailored  to  users’  specific  needs,  state-of-the-art  physical  models,  automated  weather  data 
ingest,  access  to  geographic  databases,  customized  targets  and  sensors,  and  a  target  scene 
visualization  capability.  TAWS  is  being  developed  in  five  stages  to  achieve  incremental, 
user-oriented  development. 

1.1.3  Task  3:  Documentation 

This  task  includes  all  project  documentation.  The  following  are  planned  as  part  of 
this  contract: 


•  Quarterly  status  reports 

•  Annual  progress  reports 


2 


•  Periodic  briefings 

•  User’s  manuals  to  accompany  each  version  of  TAWS 

•  Final  technical  report 


1.2  PROGRESS  SUMMARY 

This  report  is  the  first  Interim  Report  for  Contract  Number  F19628-97-C-0087. 
This  report  covers  the  first  year  of  the  WIDA  program,  from  22  August  1997  through  31 
August  1998. 


1.3  REPORT  ORGANIZATION 

This  report  contains  five  main  sections.  Section  2  describes  the  progress  made  on 
Task  1,  WAMPS.  Section  3  describes  the  progress  made  on  Task  2,  TAWS.  Section  4 
describes  the  progress  made  on  Task  3,  Documentation.  Finally,  Section  5  discusses 
plans  in  each  of  these  task  areas  for  the  upcoming  year. 
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2  TASK  1:  WEATHER  AUTOMATED  MISSION  PLANNING 
SOFTWARE  (WAMPS) 

The  purpose  of  this  task  is  to  develop  demonstratable  prototypes  of  a  Weather 
Automated  Mission  Planning  Software  (WAMPS)  system.  The  prototypes  are  intended  to 
show  how  WIDAs,  when  integrated  in  automated  mission  planning  systems,  can  support 
and  improve  the  mission  planning  process.  The  WAMPS  prototypes  are  being  developed 
in  four  stages.  Focal  points  are  identification  of  appropriate  mission  planning  systems, 
overall  system  look  and  feel,  integration  of  key  databases,  execution  of  WIDA  models, 
and  demonstration  of  value  added. 

This  task  includes  work  in  three  areas:  requirements  analysis,  development  of 
WAMPS  software  prototypes,  and  demonstration  of  value  added  to  the  mission  planning 
process.  Work  in  each  of  these  areas  during  the  first  year  of  the  project  is  described 
below. 


2.1  REQUIREMENTS  ANALYSIS 

Requirements  analysis  was  the  primary  focus  of  our  efforts  on  WAMPS  during 
the  first  year  of  the  project.  We  interacted  with  AFRL  Hanscom,  AFRL  Rome,  and  Air 
Combat  Command  (ACC)  in  order  to  help  establish  requirements.  We  continued  to 
improve  our  depth  of  understanding  of  the  mission  planning  process.  We  analyzed  design 
documents  and  specifications  for  current  and  evolving  mission  planning  systems, 
focusing  in  particular  on  the  Theater  Battle  Management  Core  Systems  (TBMCS).  We 
pursued  opportunities  to  observe  all  phases  of  the  mission  planning  process  during 
training  exercises  such  as  Blue  Flag.  We  worked  with  AFRL  to  develop  a  set  of  WAMPS 
requirements  as  a  result  of  these  activities.  These  requirements  are  now  being  used  in  the 
development  of  the  initial  prototype. 

A  project  kickoff  meeting  with  AFRL  was  held  at  TASC  on  16  September  1997 
and  included  discussion  of  the  initial  WAMPS  requirements.  Discussion  centered  on  the 
focus  of  the  WAMPS  prototype,  stressing  the  importance  of  the  look  and  feel  of  a 
mission  planning  system  with  sample  data  and  weather  effects,  but  without  the  interfaces 
to  actual  weather  data  or  effects  models.  A  decision  was  made  to  meet  at  ACC  to  obtain 
feedback  from  actual  mission  planners  and  from  the  potential  user  community. 
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A  meeting  was  held  at  ACC  on  16  October  1997  that  included  discussions  on  the 
WAMPS  prototype.  Several  mission  planning  systems  were  noted  as  candidates  for  the 
look  and  feel  of  the  WAMPS  prototype.  The  Advanced  Planning  System  (APS),  the 
Force  Level  Execution  System  (FLEX),  and  D.ARPA’s  Joint  Force  Air  Component 
Commander  (JFACC)  system  were  all  covered.  Additionally,  exercises  such  as  Blue  Flag 
and  Joint  Task  Force  Exercise  (JTFX)  were  mentioned  as  being  potentially  useful  to 
observe  to  see  mission  planning  systems  in  use. 

Following  the  meetings,  we  contacted  Bob  Farrell  at  ,AERL  Rome  to  further 
discuss  requirements  and  evaluate  candidate  programs  to  emulate.  We  began  to  evaluate 
where  in  the  mission  planning  process  weather,  and  specifically  WIDAs,  could  be  fit  in 
with  a  WAMPS  prototype.  The  Air  Tasking  Order  (ATO)  generation  process  where 
aircraft,  weapons  systems,  and  targets  are  matched  seemed  the  best  candidate.  We 
obtained  information  about  FLEX  and  APS,  in  preparation  for  scheduling  demonstrations 
of  these  systems. 

We  traveled  to  AFRL  Rome  on  13  January  1998  to  see  demonstrations  of  APS 
and  FLEX.  In  conjunction  with  AFRL,  we  determined  that  the  step  in  the  mission 
planning  process  that  monitors  and  re-plans  tasked  missions  (as  required  by  weather, 
losses,  combat  events,  cancellations,  etc.)  would  be  the  most  useful  step  in  which  to 
initially  show  value  added  by  WIDAs.  This  step  is  handled  by  the  Computer  Assisted 
Force  Management  System  (CAFMS)  in  the  current  Contingency  Theater  Automated 
Planning  System  (CTAPS)  and  will  be  handled  by  FLEX  in  the  TBMCS.  Also  in 
conjunction  with  AFRL,  we  determined  that  WAMPS  should  emulate  the  look  and  feel  of 
the  future  system  TBMCS,  as  opposed  to  the  current  system  CTAPS.  TBMCS  is 
scheduled  for  deployment  in  late  1998.  We  recommended  to  AFRL  that  the  WAMPS 
prototype  be  interactive,  run  in  a  Web  Browser,  and  be  accessed  either  from  a  Web 
Server  via  the  Internet  or  from  local  disk  on  a  portable  system.  These  recommendations 
were  accepted. 

Based  on  these  decisions,  we  prepared  a  requirements  specification  document  for 
WAMPS.  This  requirements  document  focuses  on  two  components  of  WAMPS:  1)  the 
demonstration  of  value  added  by  exploiting  weather  information  during  the  mission 
planning  process  and  2)  the  demonstration  of  how  this  added  value  can  be  achieved  in  the 
context  of  the  mission  planning  process.  We  briefed  the  WAMOPS  Requirements 
Document  to  AFRL  on  21  May  1998.  AFRL  accepted  the  concepts  presented,  and  this 
became  the  planning  specification  for  the  WA\LPS  prototypes.  A  copy  is  presented  in 
Appendix  A. 
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We  learned  from  AFRL  that  the  January  1998  JTFX  did  not  have  an  Air  Force 
component.  Later,  plans  to  instead  attend  the  May  1998  session  were  also  derailed  when 
the  exercise  was  cancelled.  We  also  learned  that  there  were  difficulties  in  registering  for 
the  February  1998  Blue  Flag  exercise.  Instead,  we  attended  a  CTAPS  operator/technician 
course  at  Hurlburt  AFB,  FL,  in  April  1998.  This  course  allowed  us  to  understand  more 
completely  the  mission  planning  and  ATO  generation  process. 


2.2  PROTOTYPES 

No  prototypes  were  completed  during  during  the  first  year  of  the  project.  During 
the  period  June  August  1998,  scenarios  for  the  WAMPS  prototype  were  discussed  and 
developed,  and  the  initial  PowerPoint  briefing  slides  that  would  constitute  the  first 
prototype  were  initiated.  The  slides  were  Web-based,  with  self-briefing  formats  With 
AFRL  approval,  WAMPS  activity  was  decreased  in  order  to  apply  more  effort  to  the 
initial  TAWS  software  development. 


2.3  DEMONSTRATION  OF  VALUE  ADDED  BY  WAMPS  TO  THE  MISSION. 
PLANNING  PROCESS 

There  was  no  activity  in  this  area  during  during  the  first  year  of  the  project,  other 
than  that  associated  with  developing  the  requirements  in  the  Requirements  Document. 
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3  TASK  2:  TARGET  ACQUISITION  WEATHER  SOFTWARE 
(TAWS) 

The  purpose  of  this  task  is  to  develop  Target  Acquisition  Weather  Software 
(TAWS)  to  replace  the  DOS-based  EO  Tactical  Decision  Aid  (EOTDA),  taking 
advantage  of  modeling  and  hardware/software  technology  improvements.  TAWS  is 
intended  to  support  the  mission  execution  process.  Eventually,  TAWS  may  be  used  as  a 
baseline  system  to  integrate  into  the  mission  planning  process,  perhaps  providing  the 
technology  to  feed  the  WAMPS  environment  described  above.  TAWS  is  being  developed 
in  five  stages  to  achieve  incremental,  user-oriented  development. 

This  task  includes  work  in  nine  areas:  development  of  the  TAWS  system 
architecture,  development  of  a  GUI,  design  and  development  of  TAWS  output  products, 
upgrades  to  the  TAWS  physical  models,  implementation  of  automated  weather  access, 
incorporation  of  improved  geographic  data,  development  of  customized  sensors, 
development  of  customized  targets,  and  implementation  of  target  scene  visualization. 
Work  in  each  of  these  areas  during  the  first  year  of  the  project  is  described  below.  Work 
in  the  areas  of  Navy  and  Army  requirements  is  also  described. 


3.1  TAWS  SYSTEM  ARCHITECTURE 

Development  of  the  TAWS  system  architecture  was  the  primary  focus  of  our 
efforts  on  TAWS  during  the  first  six  months  of  the  project.  TAWS  incorporates  a 
modular  system  design  in  an  object-oriented  environment.  We  worked  with  AFRL  to 
specify  the  TAWS  system  requirements.  We  incorporated  these  requirements  into  a 
concept  of  operations  document,  which  included  a  functional  decomposition,  a  data  flow 
description,  and  a  user-oriented  process  flow  description.  We  then  developed  the  object- 
oriented  design  of  the  TAWS  core  code.  The  design  documents  are  now  being  used  in  the 
development  of  the  TAWS  Graphical  User  Interface  (GUI). 

A  project  kickoff  meeting  with  AFRL  was  held  at  TASC  on  16  September  1997 
and  included  discussion  of  the  TAWS  architecture.  The  overarching  concept  was  to 
leverage  work  previously  done  in  the  Night  Vision  Goggles  Operations  Weather 
Software  (NOWS)  to  a  similar  architecture  for  TAWS.  A  meeting  with  users  was  held  at 
HQ  Air  Combat  Command  (ACC)  on  16  October  1997,  and  this  concept  was  solidified. 
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Following  the  meetings,  we  put  together  a  Concept  of  Operations  (CONOPS)  for 
TAWS.  The  CONOPS  describes  the  functional  components  of  the  TAWS  system,  the 
user  interface  flow,  the  data  flow,  and  the  high-level  software  design.  The  CONOPS  was 
presented  to  AFRL  on  8  December  1997.  Based  on  feedback  received  at  AFRL,  we 
updated  the  CONOPS  and  presented  it  to  AFRL  and  the  Naval  Research  Laboratory 
(NTIL)  on  6  January  1998.  The  revised  CONOPS  is  included  in  Appendix  B. 

In  conjunction  with  the  CONOPS,  we  developed  a  diagram  depicting  the  overall 
TAWS  system  architecture  concept.  This  is  shown  in  Figure  2.  The  concept  shows  the 
TAWS  core  code,  or  TAWS  GUI,  controlling  a  series  of  physical  models  and  a  series  of 
modular  processes.  This  process  flow  concept  is  detailed  in  Figure  3.  The  TAWS  core 
code  accesses  external  databases  when  necessary  and  creates/accesses  internal  databases 
when  necessary.  This  data  flow  concept  is  detailed  in  Figure  4.  The  intent  is  to  add  new 
processes  or  data  sources  to  the  overall  TAWS  system  architecture  as  they  become 
available  for  each  version. 


TAWS 

Databases 


External 

Databases 


Figure  2.  TAWS  Architecture  Concept. 
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Figure  3.  TAWS  Process  Flow  Concept. 


Defaults 

Database 


Figure  4.  TAWS  Data  Flow  Concept. 
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Following  the  CONOPS  and  the  overall  TAWS  system  architecture  concept,  we 
developed  an  object-oriented  design  for  the  TAWS  core  code.  We  presented  this  design 
to  AFRL  on  2  February  1998.  The  plan  was  to  use  the  same  underlying  design  for  TAWS 
and  NOWS,  reusing  as  many  of  the  core  objects  as  possible  and  keeping  the  codes  in  co¬ 
development.  AFRL  approved  the  object-oriented  design,  and  implementation  began. 


3.2  TAWS  GRAPHICAL  USER  INTERFACE  (GUI) 

Development  of  the  TAWS  GUI  was  the  primary  focus  of  our  efforts  during  the 
second  six  months  of  the  project.  The  TAWS  GUI  used  the  NOWS  GUI  as  a  starting 
point,  and  was  modified  for  TAWS-specific  requirements,  Look-and-feel  changes  were 
also  made  based  on  NOWS  user  feedback.  A  representation  of  the  high-level  TAWS  GUT 
design  is  shown  in  Figure  5. 


Figure  5.  TAWS  GUI  Concept, 

Although  the  initial  plan  called  for  development  of  the  TAWS  GUI  in  the  Galaxy 
environment,  Visix,  the  company  that  developed  the  GALAXY  cross-platform 
development  environment  used  for  the  NOWS  GUI,  went  out  of  business  in  March  1998. 
We  evaluated  several  options  for  the  continued  development  of  the  TAWS  GUI  and 
presented  our  findings  to  AFRL  on  9  April  1998.  We  recommended  to  AFRL  that  we 
transition  NOWS  to  Microsoft  Visual  and  develop  the  TAWS  GUI  entirely  in 
Visual  C++.  The  advantages  of  this  approach  were  many:  better  support  for  Windows 
95/NT  and  future  versions  of  Windows;  easy  access  to  standard  GUI  controls  such  as 
buttons,  menus,  wizards,  tabs,  dialog  boxes,  etc.;  ability  to  adopt  a  standard  Microsoft 
product  look-and-feel,  and  better  code  maintainability.  AFRL  concurred,  and  we  began  to 
implement  the  object-oriented  design  in  Visual  C++.  Two  samples  from  the  TAWS  GUI 
are  shown  in  Figure  6. 
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Figure  6.  Samples  of  the  TAWS  GUI. 


We  began  to  assemble  a  prototype  of  the  TAWS  GUI  and  to  prepare  for  a 
preliminary  TAWS  Beta  Version  design  review. 


3.3  TAWS  OUTPUT  PRODUCTS 

There  was  no  work  in  this  area  during  the  first  year  of  the  project. 

3.4  PHYSICAL  MODELS 

The  TAWS  physical  models  (3-5  pm  and  8-12  pm  infrared,  1.06  pm  laser,  and 
television/NVG)  were  ported  from  the  DOS-based  Microsoft  FORTRAN  compiler  used 
for  the  EOTDA  Version  3.1  to  the  Digital  Visual  FORTRAN  compiler.  The  new 
compiler  identified  several  problems  associated  with  the  IR  model,  and  these  problems 
were  corrected.  Testing  verified  that  results  with  the  newly-compiled  code  were 
consistent  with  EOTDA  results.  The  plan  for  TAWS  Beta  is  not  to  change  the  physics  of 
the  models,  but  to  port  the  EOTDA  3.1  models,  with  the  3-5  pm  upgrade,  to  the  new 
TAWS  environment. 


3.5  AUTOMATED  WEATHER 

A  series  of  communications  brought  forth  the  requirement  for  an  early  version  of 
TAWS  to  include  a  connection  to  the  Air  Force  Weather  Agency  (AFWA)  to  receive 
automated  weather  as  a  form  of  initializing  the  TAWS  defaults.  Initial  contact  was  made 


13 


with  AFWA,  and  work  began  to  definitize  the  type  of  connection,  security  requirements, 
and  other  details  of  the  format. 


3.6  GEOGRAPHIC  DATABASES 

There  was  no  work  in  this  area  during  the  first  year  of  the  project.  The  decision 
was  made  for  the  TAWS  Beta  Version  to  use  the  same  geographic  databases  as  NOWS, 
the  National  Imagery  and  Mapping  Agency's  (NIMA's)  Vector  Smart  Map  Level  0  for 
mapping  data  and  the  DeFries  and  Townshend  Land  Cover  Classification  Map  (1994a) 
for  default  background  information  for  a  user-specified  target  location. 


3.7  CUSTOMIZED  SENSORS 

There  was  no  work  in  this  area  during  the  first  year  of  the  project. 

3.8  CUSTOMIZED  TARGETS 

There  was  no  work  in  this  area  during  the  first  year  of  the  project. 

3.9  VISUALIZATION 

TASC  investigated  a  variety  of  options  for  the  visualization  component  of  TAWS. 
A  meeting  at  AFRL  on  22  December  1997  covered  the  details  of  the  Infrared  Target 
Scene  Simulation  (IRTSS)  software.  Since  components  of  IRTSS  are  scheduled  to  be 
integrated  into  TAWS,  it  was  decided  to  use  IRTSS  methodologies  in  TAWS  as  much  as 
possible  to  reduce  code  development.  Because  IRTSS  uses  OpenGL  for  target  scene 
visualization,  and  OpenGL  drivers  are  available  for  the  Windows  95/NT  platforms,  it  was 
decided  to  use  OpenGL  for  the  TAWS  visualization  component.  TASC  developed  a 
rudimentary  visualization  capability  focusing  on  the  visualization  of  inherent  target 
radiance  for  the  visible  wavelength  region.  T.ASC  developed  the  necessary  OpenGL 
application  interfaces,  built  OpenGL  utility  libraries  for  use  with  Windows  95/NT, 
developed  code  to  access  the  3-D  target  geometry  files,  implemented  code  to  construct  a 
target  wire-frame  drawing,  added  controls  for  viewpoint  manipulation,  implemented 
rendering  of  high-resolution,  device-independent  bitmap  imagery,  and  incorporated  gray¬ 
scale  shading  based  on  TV  model  inherent  target  radiance  results.  The  code  developed 
should  be  extendable  to  IR  model  inherent  temperature  results. 
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3.10  ARMY  AND  NAVY  INCLUSION  INTO  TAWS 

A  contract  engineering  change  proposal  (ECP)  was  negotiated  to  add  Navy 
requirements  to  the  TAWS  effort.  This  change  included  the  following  major  components; 

•  Incorporate  Navy  targets  and  sensors 

•  Incorporate  automated  weather  download  from  Navy  sources 

•  Incorporate  Navy  model  improvements 

Additionally,  talks  were  started  with  Army  representatives  to  show  how  Army 
inclusion  into  the  TAWS  program  at  this  point  could  benefit  Army  operators  and 
leverage  current  work  being  done  by  Air  Force  and  Navy.  Initial  discussions  have  been 
very  positive. 
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4  TASK  3:  DOCUMENTATION 


The  purpose  of  this  task  is  to  provide  periodic  project  progress  reports,  periodic 
briefings,  and  software  documentation.  Progress  made  in  these  areas  during  the  first  year 
of  the  project  is  described  below. 


4.1  QUARTERLY  PROGRESS  REPORTS 

Quarterly  progress  reports  were  submitted  to  AFRL  on  23  December  1997,  13 
March  1998,  15  June  1998,  and  15  September  1998,  providing  technical  and  financial 
summaries  of  work  completed  during  the  first  year  of  the  project. 


4.2  PERIODIC  BRIEFINGS 

Periodic  briefings  were  given  to  describe  project  status  and  to  review  system’ 
designs.  A  project  kickoff  meeting  with  AFRL  was  held  at  TASC  on  16  September  1997. 
A  project  kickoff  meeting  was  held  at  ACC  on  16  October  1997. 

We  briefed  the  WAMPS  Requirements  Document  to  AFRL  on  21  May  1998. 

Briefings  on  TAWS  were  conducted  periodically  with  AFRL.  The  TAWS 
Concept  of  Operations  was  presented  to  AFRL  on  8  Decernber  1997;  a  modified 
CONOPS  was  presented  to  AFRL  and  NRL  on  6  January  1998.  The  object-oriented 
design  for  the  TAWS  core  code  was  presented  to  AFRL  on  2  February  1998.  We 
presented  options  for  the  development  of  the  TAWS  GUI  to  AFRL  on  9  April  1998. 

On  24-25  March  1998,  TAWS  and  WAMPS  briefings  were  presented  at  the 
annual  WIDA  Conference  at  Langley  AFB,  VA. 

A  TAWS  briefing  was  presented  to  the  US  Army  DAMO/FDI  on  12  August 

1998. 

4.3  SOFTWARE  DOCUMENTATION 

TASC  established  a  documentation  process  to  together  the  various  elements  of  the 
TAWS  GUI.  Developmental  use  cases  were  compiled  for  each  of  the  TAWS  processes. 
Each  of  these  documents  provides  an  operational  description  of  the  component  process. 
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describes  the  dialogs  or  user  input  screens  which  must  be  written  to  support  the 
component,  and  itemizes  which  objects  (or  classes)  the  component  must  access.  The 
documents  will  be  used  in  the  further  development  of  the  TAWS  GUI,  and  to  make  sure 
that  all  requirements  are  met. 
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5  PLANS  FOR  NEXT  YEAR 


Plans  for  next  year  include  the  following: 

•  Completion  of  the  first  and  second  WAMPS  Prototypes 

•  Release  of  TAWS  Beta  and  TAWS  Version  1 

•  Addition  of  Navy  requirements  to  TAWS 

•  Addition  of  Army  requirements  to  TAWS 
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APPENDIX  A 


WEATHER  AUTOMATED  MISSION  PLANNING  SOFTWARE 

(WAMPS) 

DEMONSTRATION  PROTOTYPE 

REQUIREMENTS  DEFINITION 


1  SCOPE 


1.1  IDENTIFICATION 

This  document  establishes  requirements  for  the  Weather  Automated  Mission 
Planning  Software  (WAMPS)  demonstration  prototype. 


1.2  PURPOSE 

The  purpose  of  the  WAMPS  demonstration  prototype  is  to  impress  upon  the 
mission  planning  community  and  warfighting  policy-makers  how  weather,  and 
specifically  Weather  Impact  Decision  Aids  (WIDAs),  can  benefit  the  mission  planning 
process.  The  prototype  will  demonstrate  how  we  can  use  weather  and  WIDAs  as  force 
multipliers  in  automated  mission  planning  systems  by  facilitating  the  effective  use  of 
Electro-Optical  weapon  systems  against  enemy  targets. 
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1.3  BACKGROUND 


In  the  modern  warfighter  era,  where  we  may  fly  thousands  of  sorties  over  a  very 
short  period  of  time,  we  rely  on  automation  to  plan,  execute  and  re-plan  missions  quickly 
enough  so  that  enemy  forces  are  absolutely  overwhelmed  with  our  military  superiority. 
Although  weather  plays  a  critical  role  in  the  success  or  failure  of  many  missions,  we  have 
not  integrated  weather  into  the  automated  planning  process.  As  a  result,  missions  that 
could  have  been  successful  do  not  succeed  because  we  do  not  properly  consider  weather 
impacts  when  we  plan  the  missions. 

There  is  significant  value  in  exploiting  weather  information  and  WIDAs  across 
the  full  spectrum  of  mission  planning  and  execution.  During  the  long  range  mission 
planning  process,  weather  is  used  to  select  targets,  weapons  systems,  and  broad  tactics. 
As  the  Air  Tasking  Order  (ATO)  is  generated,  weather  and  WIDA  impacts  on  weapons 
system  performance  could  be  used  to  refine  time-over-target  schedules,  battle  tactics,  and 
weapons  system  allocations.  During  the  execution  phase,  mission  monitoring,  aborts, 
battle  damage  assessments  (BDA),  and  re-planning  are  all  weather  and  WIDA  - 
dependent. 

A  significant  impact  to  full  integration  of  weather  and  WIDA  has  been  the- 
laborious,  manpower-intensive  process  for  applying  weather  information.  With  the 
automation  of  many  meteorological  functions,  including  determination  of  weather 
impacts,  these  data  can  be  integrated  with  the  advances  in  automation  of  mission 
planning  and  execution  functions.  For  the  Air  Force,  the  future  Theater  Battle 
Management  Core  Systems  (TBMCS)  automated  mission  planning  systems,  specifically 
Theater  Air  Planning  (TAP)  for  ATO  generation  and  Force  Level  Execution  (FLEX) 
system  for  mission  monitoring  and  re-planning  are  ideal  candidates  for  the  inclusion  of 
automated  weather  and  WIDA  tools. 

Specific  weather  phenomena  affect  specific  weapons  systems.  For  example,  : 

•  Haze  and/or  fog  can  prevent  a  successful  lock-on  for  television  guided 

weapons. 

•  Infrared  sensors,  operating  at  3-5  um  or  8-12  um  are  seriously  degraded 

by  high  values  of  absolute  humidity. 

•  Laser  guided  munitions  have  their  designator  beam  attenuated  by 

aerosols  along  the  beam  path. 

The  WIDAs  have  been  developed  to  assist  mission  planners  in  the  selection  and 
use  of  these  various  precision  weapons  systems. 
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One  such  WIDA  is  the  Electro-Optical  Tactical  Decision  Aid  (EOTDA).  This 
software  model  predicts  the  performance  of  air-to-ground  weapon  systems  and  direct 
view  optics  based  on  environmental  and  tactical  information.  The  environmental 
information  includes  weather  forecast  information.  The  EOTDA  expresses  performance 
in  terms  of  maximum  detection  or  lock-on  range.  Typically,  mission  failure  may  occur  if 
a  weapon  is  not  able  to  achieve  lock-on  outside  of  some  minimum  lock-on  range. 
Therefore,  EOTDA  generated  lock-on  range  predictions,  based  on  quality  weather 
forecasts,  and  compared  with  mission  effectiveness  criteria,  can  help  predict  potential 
mission  failure  or  success  due  to  weather  factors.  Automated  mission  planning  systems 
can  then  alert  mission  planners  at  their  consoles,  and  provide  guidance  during  re¬ 
planning,  to  maximize  the  number  of  successful  missions  and  minimize  costly  aborts 
over  target. 

For  example,  consider  a  mission  which,  due  to  tactical  constraints,  will  only  be 
successful  if  an  IR  weapon  can  lock-on  to  the  target  outside  of  4  km.  Also  consider  the 
weather  forecast,  valid  for  the  time  over  target  and  target  location.  By  using  automated 
WIDAs,  we  will  be  able  to  predict  a  lock  on  range  or  zone.  If  the  predicted  zone  is  7-10 
km  then  the  mission  is  predicted  to  be  successful.  If  the  predicted  zone  is  1-2  km  then 
the  mission  is  predicted  to  be  unsuccessful.  If  the  predicted  zone  is  3-5  km  then  the' 
mission  may  or  may  not  be  successful.  Mission  planners  would  receive  automatic  alerts 
in  the  latter  two  results. 

Much  of  the  information  required  by  the  EOTDA  is  already  available  in 
automated  mission  planning  systems.  The  remaining  information,  including  weather 
information,  can  also  be  made  available,  so  that  automated  mission  planning  systems  may 
execute  EOTDAs,  compare  the  results  with  mission  effectiveness  criteria,  and  predict 
potential  mission  failure  due  to  weather  for  each  planned  or  re-planned  mission. 


1.4  APPROACH 

With  effective  content,  evolution,  and  distribution,  the  WAMPS  demonstration 
prototype  will  show  how  weather  and  WIDAs,  specifically  the  EOTDA,  can  benefit  the 
mission  planning  process.  In  addition  to  demonstrating  integration  of  WIDA  into  the 
mission  planning  process,  the  program  will  illustrate,  in  a  quantitative  sense,  the  value- 
added  of  this  critical  information. 

The  program  will  evolve  through  four  distinct  phases,  each  one  showing  both 
planning  aspects  and  value-added  aspects.  The  four  phases,  broadly  described,  are  as 
follows: 
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•  Phasel:  A  user-controlled  slide  show  that  illustrates  a  representative 
graphical  user  interface  (GUI).  The  user  is  intended  to  be  anyone  who 
interacts  with  the  GUI,  and  can  include  AFRL,  mission  planners, 
TASC,  or  other  appropriate  persons,  Scenario  data  is  predetermined  to 
highlight  the  capability  of  WAMPS. 

•  Phase  2:  The  predetermined  scenarios  are  expanded  to  increase  the 
number  of  missions,  and  will  allow  interactive  functionality.  Actual 
EOTDA  computations  will  be  made,  alerts  provided  to  mission 
planners,  and  illustration  made  of  the  ability  to  influence  mission 
planning  and  the  ATO  through  WAMPS. 

•  Phase  3;  Adds  the  ability  to  mimic  mission  monitoring  and 
replanning. 

•  Phase  4:  Incorporates  new  requirements  based  on  feedback  on 
previous  phases. 

The  prototype  shall  evolve  in  response  to  feedback  from  the  mission  planning 
community  and  users  who  are  exposed  to  the  WAMPS  prototype.. 

To  ensure  maximum  exposure  and  subsequent  feedback,  the  prototype  shall  be 
available  via  the  Internet  on  the  World  Wide  Web. 


2  REQUIREMENTS 


2.1  DESCRIPTION 

The  WAMPS  demonstration  prototype  shall  be  a  self-guided,  interactive  software 
system  consisting  of  I)  The  WAMPS  Planning  Demo  which  will  demonstrate  how  the 
specific  addition  of  WIDA  information  can  be  achieved  in  the  context  of  the  mission 
planning  process,  and  2)  The  WAMPS  Value  Demo  which  will  quantify  the  value  of 
exploiting  weather  information  during  the  mission  planning  process. 


2.2  GENERAL  REQUIREMENTS 

2.2.1  The  WAMPS  prototype  system  shall  be  interactive,  run  in  a  web  browser,  and  be 
hosted  on  a  web  server  that  can  be  accessed  from  the  Internet. 
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2.2.2  The  WAMPS  prototype  system  shall  also  be  hosted  on  a  portable,  stand-alone 
web  server,  to  be  demonstrated  at  locations  without  Internet  access. 

2.2.3  The  WAMPS  prototype  system  shall  present  introductory  slides  that  describe  the 
purpose  of  the  prototype. 

2.2.4  The  WAMPS  prototype  system  shall  provide  guiding  textual  narrative  with  each 
slide,  as  well  as  context-sensitive  help  screens. 

2.2.5  The  WAMPS  prototype  system  shall  be  developed  iteratively  and  delivered  in 
four  phases. 

2.2.6  Each  phase  shall  meet  the  requirements  of  all  previous  phases  and  shall  be 
enhanced  to  incorporate  new  requirements,  agreed  upon  by  AFRL  and  TASC, 
based  on  feedback  from  users  regarding  previous  phases. 


2.3  WAMPS  PLANNING  DEMO  REQUIREMENTS 

2.3.1  WAMPS  Planning  Demo  in  Phase  1 

2.3. 1.1  The  WAMPS  Planning  Demo  in  Phase  1  shall  be  a  user-controlled  slide  show 
that  demonstrates  a  representative  GUI  for  interacting  with  the  WAMPS. 

2.3. 1.2  The  WAMPS  Planning  Demo  in  Phase  1  shall  present  a  series  of  slides  that 
mimic  the  functions  of  planning,  monitoring,  and  re-planning  a  single  mission 
(i.e.,  the  marquee  of  mission  monitoring  time  lines  and  re-planning  dialog 
panels).  Anticipating  the  USAF  migration  into  the  TBMCS  era,  this  slide  show 
will  use  the  TAP  and  FLEX  marquees  to  illustrate  how  WAMPS  could  benefit 
the  mission  planning  process. 

2.3. 1.3  The  WAMPS  Planning  Demo  in  Phase  1  shall  present  a  slide  that  shows  how  a 
mission  planner  might  enter  mission  effectiveness  alert  thresholds.  This  shall 
include  the  minimum  acceptable  lock-on  range. 

2.3.1 .4  The  WAMPS  Planning  Demo  in  Phase  1  shall  present  a  slide  that  shows  an  alert 
on  the  mission  monitoring  time  line,  indicating  that  the  effectiveness  criteria  fall 
below  the  internally  stored  thresholds  due  to  mission-limiting  weather 
conditions. 

2.3. 1.5  The  WAMPS  Planning  Demo  in  Phase  1  shall  present  a  slide  that  shows  the 
mission  re-planning  dialog  panels,  augmented  by  the  availability  of  new 
WAMPS  decision  support  tools. 
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2. 3. 1.6  The  WAMPS  Planning  Demo  in  Phase  1  shall  present  examples  of  the  WAMPS 
decision  support  output  products  that  graphically  display  windows  of 
opportunity,  wherein  the  mission  effectiveness  criteria  are  satisfied.  These  shall 
include  the  following: 

•  Time  windows  for  selected  sensors,  azimuths,  and  altitudes 

•  Azimuth  windows  for  selected  sensors,  times,  and  altitudes 

•  Altitude  windows  for  selected  sensors,  times,  and  azimuths 

2.3. 1.7  The  WAMPS  Planning  Demo  in  Phase  1  shall  present  a  slide  that  indicates  a 
change  in  alert  status  (e.g.,  remove  the  warning  of  potential  mission  failure  from 
the  screen)  of  the  re-planned  mission. 

2.3. 1.8  The  WAMPS  Planning  Demo  in  Phase  1  shall  solicit  feedback  from  AFRL, 
mission  planners,  and  other  appropriate  users  in  order  to  properly  evolve  the 
system. 

2.3.2  WAMPS  Planning  Demo  in  Phase  2 

2.3.2. 1  The  WAMPS  Planning  Demo  in  Phase  2  shall  focus  on  several  pre-defined- 
missions,  agreed  upon  by  AFRL  and  TASC,  to  demonstrate  WAMPS  for  a 
variety  of  weather/target  scenarios  during  the  mission  planning  process 

2. 3. 2. 2  The  WAMPS  Planning  Demo  in  Phase  2  shall  present  a  series  of  slides  that 
mimics  the  TAP  function  of  weaponeering  to  generate  an  ATO,  augmented  by 
the  availability  of  new  WAMPS  decision  support  tools. 

2. 3. 2. 3  The  WAMPS  Planning  Demo  in  Phase  2  shall  be  interactive,  displaying  changes 
in  the  mission  alert  status  in  response  to  user-selected  mission  effectiveness 
thresholds  and  user  re-planned  mission  parameters  (sensor,  time,  azimuth  and 
altitude).  The  user  shall  be  able  to  access  the  decision  support  output  products, 
in  which  changes  will  also  be  displayed. 

2. 3. 2. 4  The  WAMPS  Planning  Demo  in  Phase  2  shall  look  up  these  changes  from  a 
database  of  mission  effectiveness  results  computed  from  a  series  of  EOTDA 
runs  which  correspond  to  the  weather/target  scenarios.  Results  will  exist  for  all 
possible  mission  effectiveness  threshold/mission  parameter  combinations 
available  to  the  user. 

2. 3. 2. 5  The  WAMPS  Planning  Demo  in  Phase  2  shall  solicit  feedback. 
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2.3.3  WAMPS  Planning  Demo  in  Phase  3 

2.3.3. 1  The  WAMPS  Planning  Demo  in  Phase  3  shall  mimic  mission  monitoring  and  re¬ 
planning  functions  of  the  mission  planning  process,  operating  on  a  test-bed 
version  of  the  current  mission  planning  database,  which  will  be  mocked  up  to 
contain  canned  data  for  several  missions.  It  will  carry  forward  the  FLEX 
marquee  demonstrated  in  Phase  1 . 

2. 3. 3. 2  The  test-bed  database  schema  shall  be  expanded,  as  necessary,  to  include 
parameters  needed  to  support  computation  of  mission  effectiveness. 

2. 3. 3. 3  There  shall  be  a  default  set  of  active  database  parameters  which,  when  altered, 
trigger  re-computation  of  mission  effectiveness  results,  and  trigger  alerts  as 
necessary. 

2. 3. 3. 4  The  initial  default  set  of  active  database  parameters  shall  be  all  those  that  can 
effect  the  resulting  mission  effectiveness.  The  user  shall  be  able  to  override  the 
default  set  of  database  parameters  to  be  any  subset  of  the  initial  default  set. 

2. 3. 3. 5  Upon  start-up,  the  WAMPS  Planning  Demo  in  Phase  3  shall  make  the  necessary 
EOTDA  runs  and  compute  mission  effectiveness  results  for  all  missions  in  the 
test-bed  database,  using  the  corresponding  mission  data. 

2. 3. 3. 6  The  WAMPS  Planning  Demo  in  Phase  3  shall  solicit  feedback. 

2.3.4  WAMPS  Planning  Demo  in  Phase  4 

2.3.4. 1  The  WAMPS  Planning  Demo  in  Phase  4  shall  be  enhanced  to  incorporate  new 
requirements,  agreed  upon  by  AFRL  and  TASC,  based  on  feedback  on  previous 
phases. 


2.4  WAMPS  VALUE  DEMO  REQUIREMENTS 

2.4.1  WAMPS  Value  Demo  in  Phase  1 

No  activity  in  this  phase. 

2.4.2  WAMPS  Value  Demo  in  Phase  2 

2.4.2. 1  The  WAMPS  Value  Demo  in  Phase  2  shall  be  a  user-controlled  slide  show, 
clearly  illustrating  in  a  quantitative  manner  the  value-added  of  weather  and 
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WIDA  in  the  mission  planning  process.  This  will  be  implemented  in  limited 
fashion  only  for  this  phase. 

2.4. 2.2  Based  on  AFRL  and  user  feedback,  metrics  may  be  tuned  or  further  defined  to 
best  illustrate  the  value-added. 

2.4.3  WAMPS  Value  Demo  in  Phase  3 

2.4.3. 1  The  WAMPS  Value  Demo  shall  consist  of  an  interactive  display  engine  and  a 
database. 

2. 4. 3. 2  The  database  shall  contain  pre-computed  values  of  previously  agreed-upon 
metrics,  which-independent  of  target,  background,  approach  azimuth  or 
altitude— reflect  the  impact  of  weather  and  WIDAs  on  mission  effectiveness. 

2. 4. 3. 3  Metrics  shall  be  computed  for  combinations  of  the  following  categories: 

•  Mission  effectiveness  criterion— a  lock-on  range  threshold  which,  if 

realized,  determines  mission  success 

•  Weather  category— good,  marginal,  or  poor  overall  weather 

environments 

•  Sensor  type— one  each  chosen  from  IR,  TV,  or  Laser 

over  a  predefined  ensemble  of  mission  scenarios  which  vary  with  respect  to  a 
range  of  mission  parameters.  In  general,  successful  scenarios  shall  occur  when 
mission  success  is  predicted  and  can  be  achieved  under  actual  conditions,  or 
when  mission  failure  is  predicted  and  occurs  under  actual  conditions.  Failed 
scenarios  will  occur  when  mission  success  is  predicted  but  cannot  be  achieved 
under  actual  conditions,  or  when  mission  failure  is  predicted  but  mission 
succeeds  under  actual  conditions. 

2. 4. 3. 4  The  display  GUI  will  allow  the  user  to  select  various  representations  of  the 
values  to  display. 

2.4.4  WAMPS  Value  Demo  in  Phase  4 

2.4.4. 1  The  WAMPS  Value  Demo  in  Phase  4  shall  be  enhanced  to  incorporate  new 
requirements,  agreed  upon  by  AFRL  and  TASC,  based  on  feedback  from 
previous  phases. 
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APPENDIX  B 


TARGET  ACQUISITION  WEATHER  SOFTWARE 

(TAWS) 

SYSTEM  CONCEPT  OF  OPERATIONS 
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TAWS  SYSTEM  CONCEPT:  Objectives 
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TAWS  SYSTEM  CONCEPT:  Functional  Decomposition 
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TAWS  SYSTEM  CONCEPT:  Symbols 
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TAWS  SYSTEM  CONCEPT:  Provide  Top-Level  Options 
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TAWS  SYSTEM  CONCEPT:  Set  Defaults 


TAWS  SYSTEM  CONCEPT;  Set  Defaults  for  [x] 


TAWS  SYSTEM  CONCEPT:  Do  Solar/Lunar  Ephemeris 
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TAWS  SYSTEM  CONCEPT:  Setup  Ephemeris  Calculations 
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TAWS  SYSTEM  CONCEPT:  Perform  Ephemeris  Calculations 
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TAWS  SYSTEM  CONCEPT:  Do  Quick  Target  Analysis 
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Analysis 


TAWS  SYSTEM  CONCEPT:  Define  Target 
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TAWS  SYSTEM  CONCEPT:  Build  Custom  Target 
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TAWS  SYSTEM  CONCEPT:  Setup  Sensor  Collection 
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TAWS  SYSTEM  CONCEPT:  Ingest  Weather 
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TAWS  SYSTEM  CONCEPT:  Display/Override  Weather 
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TAWS  SYSTEM  CONCEPT:  Provide  Output  Options 
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TAWS  SYSTEM  CONCEPT:  Do  Targets  Analysis 
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TAWS  SYSTEM  CONCEPT:  Set  Current  ROI 


TAWS  SYSTEM  CONCEPT;  Setup  Targets  For  ROI 
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TAWS  SYSTEM  CONCEPT:  Setup  Sorties  For  ROI 
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TAWS  SYSTEM  CONCEPT:  Setup  Sortie  Targets 
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TAWS  SYSTEM  CONCEPT:  Modify  Selected  Sortie 
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S  SYSTEM  CONCEPT:  Setup  Analysis 
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*  By  time,  for  fixed  approach  angle 
By  approach  angle,  for  fixed  time 


